In a conventional relational database schema for storing data related to disparate items, multiple tables are created; one table for each type of item having a unique attribute structure. Each table contains a number of records, each record containing a number of fields defined by its respective table. Each field of a record can store an associated value. A benefit of relational databases is savings in storage space resulting from encapsulating common information that might otherwise be repeated across multiple records. Instead of repeating the common information, an additional table is created to store the common information, the table including a key field used to provide a unique identifier for each record in the table. Then, records in other tables that wish to refer to the common information include a key field used to reference the common record. When accessing data for a record, the relational database can use such key field entries to locate and present information from records in multiple tables as if it had been stored in one contiguous table.
A typical example of this technique involves storing data associated with customer orders. It is common that an individual customer might place more than one order. In this situation, creating a single table for customer orders, as illustrated in FIG. 1, that not only includes fields for order information, but further includes fields for customer information, such as a customer's mailing address, would result in multiple copies of the customer information where there are multiple orders associated with a single customer. Thus, the information is split across two tables, as illustrated in FIG. 2. The first table, containing record (a), stores information regarding customer orders, containing fields associated with orders, such as the kinds of items ordered, their respective quantities, and prices. The second table, containing record (b), stores customer information, with fields associated with the individual customers, such as name, address, and phone number. Additionally, each of the two tables contains a key field, identified as “CustomerNumber” in FIG. 2. In the customer information table, a key field is used to uniquely identify each customer. In the customer order table, a key field is used to reference records in the customer information table. When referring to a customer order, the key field in the customer order record is used to look up a respective record in the customer information table, thus providing the name, address, and phone number of the customer associated with the order. It is also possible to locate or relate records in the opposite direction. By locating all customer order records referring to a particular customer information record, one can retrieve all of the orders associated with the customer. The relational database structure also helps maintain the data consistency. By storing only one copy of the common data in the table associated with record (b), to make changes only the single shared record needs to be updated, rather than multiple records, possibly across multiple tables, in a database.
As described above, employing the a conventional database solution requires separate tables for each item type, with various key fields for cross-referencing various records. Unfortunately, this approach quickly becomes cumbersome when using a database to describe a very broad range of different types of items. It becomes even more cumbersome when further attempting to describe “assemblies” of items within other items. For example, one may wish to use a database to manage an inventory that accurately represents the grouping or nesting of items, such as devices placed in equipment racks, where there are many different types of devices being tracked, with the types possessing unique characteristics of interest. Under a conventional relational database approach, a solution would employ separate device tables for each device type, each including key fields to track the relationships of devices, such as grouping or clustering of devices. For instance, in order to maintain an inventory of electrical power conditioning equipment the database table might contain fields to record attributes such as device_name, serial_number, device_type, and manufacturer. The electrical power conditioning equipment might be contained in a rack assembly with other equipment such as a computer. The attributes used to describe the electrical equipment might be used to describe the computer, but additional fields may be needed to record other attributes of the computer, such as operating_system, Storage_Capacity and Programs_Loaded. Further, the entire rack assembly could be part of a subsystem of racks collectively known as a cluster. To record this, a table with a record for each rack assembly might have the attributes rack_number and cluster_name. When one device is moved out of a cluster for repair, data in respective key fields are changed to reflect its new state. Any key fields reflecting the state may have to be updated in multiple records, depending on the relationships of various items, and how the relationships are recorded by the database.
There is a need for recording information regarding a disparate collection of items in a more compact manner than a conventional relational database schema. Additionally, there is a need to record changes in relationships between items recorded in a database that reduces the number of records that must be updated to record such changes.